The introduction of the Business Vision should provide an overview of the entire document. It should include the purpose, scope, definitions, acronyms, abbreviations, references, and overview of the Business Vision.]

1.1 Purpose

[Specify the purpose of this Business Vision document.]

1.2 Scope

[A brief description of the scope of this Business Vision document; what Project(s) it is associated with, and anything else that is affected or influenced by this document.]

1.3 Definitions, Acronyms and Abbreviations

[This subsection should provide the definitions of all terms, acronyms, and abbreviations required to properly interpret the Business Vision document. This information may be provided by reference to the project Glossary.]

1.4 References

[This subsection should provide a complete list of all documents referenced elsewhere in the Business Vision.á Each document should be identified by title, report number (if applicable), date, and publishing organization.á Specify the sources from which the references can be obtained. This information may be provided by reference to an appendix or to another document.]

1.5 Overview

[This subsection should describe what the rest of the Business Vision contains and explain how the document is organized.]

2. Positioning

2.1 Business Opportunity

[Briefly describe the business opportunity being met by this project.]

2.2 Problem Statement

[Provide a statement summarizing the problem being solved by this project. The following format may be used:]

The problem of	[describe the problem]
affects	[the stakeholders affected by the problem]
the impact of which is	[what is the impact of the problem]
a successful solution would be	[list some key benefits of a successful solution]

2.3 Product Position Statement

[Provide an overall statement summarizing at the highest level, the unique position the product intends to fill in the marketplace. The following format may be used:]

For	[target customer]
Who	[statement of the need or opportunity]
The (product name)	áis a [product category]
That	[statement of key benefit; that is,- compelling reason to buy]
Unlike	[primary competitive alternative]
Our product	[statement of primary differentiation]

[A product position statement communicates the intent of the application and the importance of the project to all concerned personnel.]

3. Stakeholder and Customer Descriptions

[To effectively provide products and services that meet your stakeholdersÆ and users' real needs, it is necessary to identify and involve all of the stakeholders as part of the Requirements Modeling process.á You must also identify the users of the system and ensure that the stakeholder community adequately represents them.á This section provides a profile of the stakeholders and users involved in the project and the key problems that they perceive to be addressed by the proposed solution.á It does not describe their specific requests or requirements as these are captured in a separate stakeholder requests artifact.á Instead it provides the background and justification for why the requirements are needed.]

3.1 Market Demographics

[Summarize the key market demographics that motivate your product decisions. Describe and position target market segments. Estimate the marketÆs size and growth by using the number of potential users, or the amount of money your customers spend trying to meet needs that your product or enhancement would fulfill. Review major industry trends and technologies. Answer these strategic questions:

ò áááááááá What is your organizationÆs reputation in these markets?

òááááááááá What would you like it to be?

ò áááááááá How does this product or service support your goals?]

3.2 Stakeholder Summary

[Present a summary list of all the identified stakeholders.]

Name

Represents

Role

Name the stakeholder type.

Briefly describe what they represent with respect to the development.

[Briefly describe the role they are playing in the development.

For example, Ensure thisà.]

3.3 Customer Summary

[Present a summary list of all the identified users.]

Name

Description

Stakeholder

Name the user type

[Briefly describe what they represent with respect to the system.]

[List how the user is represented by the stakeholders.

For example, Represented by Stakeholder 1.1

3.4 Customer Environment

[Detail the working environment of the target user. Here are some suggestions:

Number of people involved in completing the task? Is this changing?

How long is a task cycle? Amount of time spent in each activity? Is this changing?

Any unique environmental constraints: mobile, outdoors, in-flight, etc.?

Which systems platforms are in use today? Future platforms?

What other applications are in use? Does your application need to integrate with them?]

3.5 Stakeholder Profilesá

[Describe each stakeholder in the system here by filling in the following table for each stakeholder.á Remember stakeholder types can be as divergent as users, strategy departments and technical developers.á A thorough profile should cover the following topics for each type of stakeholder:]

3.5.1 <Stakeholder Name>

Representative	[Who is the stakeholder representative to the project?á (optional if documented elsewhere.)á What we want here is names.]
Description	[Brief description of the stakeholder type.]
Type	[Qualify the stakeholderÆs expertise, technical background, and degree of sophisticationùthat is, guru, business, expert, casual user, etc.]
Responsibilities	[List the stakeholderÆs key responsibilities with regards to the system being developedùthat is, their interest as a stakeholder.]
Success Criteria	[How does the stakeholder define success? How is the stakeholder rewarded?]
Involvement	[How the stakeholder is involved in the project? Relate where possible to RUP workersùthat is, Requirements Reviewer etc.]
Deliverables	[Are there any additional deliverables required by the stakeholder?á These could be project deliverables or outputs from the system under development.]
Comments / Issues	[Problems that interfere with success and any other relevant information go here.]

3.6 Customer Profilesá

[Describe each unique user of the system here by filling in the following table for each customer type.á A thorough profile should cover the following topics for each type of user:]

3.6.1 <Customer Name>

Representative	[Who is the user representative to the project?á (optional if documented elsewhere.)á This often refers to the Stakeholder that represents the set of users, for example, Stakeholder: Stakeholder1.]
Description	[A brief description of the customer type.]
Type	[Qualify the customerÆs expertise, technical background, and degree of sophisticationùthat is, guru, casual user, etc.]
Responsibilities	[List the userÆs key responsibilities with regards to the system being developedù that is, captures customers details, produces reports, coordinates work, etc.]
Success Criteria	[How does the customer define success? áHow is the customer rewarded?]
Involvement	[How the customer is involved in the project? Relate where possible to RUP workersùthat is, Requirements Reviewer, etc.]
Deliverables	[Are there any deliverables the customer produces and, if so, for whom?]
Comments / Issues	[Problems that interfere with success and any other relevant information go here. These would include trends that make the customerÆs job easier or harder.]

3.7 Key Stakeholder / Customer Needs

[List the key problems with existing solutions as perceived by the stakeholder. Clarify the following issues for each problem:

òááááááááá What are the reasons for this problem?

òááááááááá How is it solved now?

òááááááááá What solutions does the user want?]

[It is important to understand the relative importance the stakeholder places on solving each problem. Ranking and cumulative voting techniques indicate problems that must be solved versus issues they would like addressed.

Fill in the following table - if using ReqPro to capture the Needs, this could be an extract or report from that tool.]

Need	Priority	Concerns	Current Solution	Proposed Solutions
Broadcast messages

3.8 Alternatives and Competition

[Identify alternatives the stakeholder perceives as available. These can include buying a competitorÆs product, building a homegrown solution or simply maintaining the status quo. List any known competitive choices that exist, or may become available. Include the major strengths and weaknesses of each competitor as perceived by the stakeholder.]

4. Business Engineering Objectives

4.1 <anObjective>

4.2 <anotherObjective>

5. Constraints

á[Note any design constraints, external constraints or other dependencies.]

6. Quality Ranges

[Define the quality ranges for performance, robustness, fault tolerance, usability, and similar characteristics that are not captured in the objectives.]

7. Precedence and Priority

[Define the priority of the different objectives.]

8. Other Requirements

[At a high-level, list applicable standards, hardware or platform requirements, performance requirements, and environmental requirements.]

8.1 Applicable Standards

[List all standards with which the business must comply. These can include legal and regulatory (FDA, UCC) communications standards (TCP/IP, ISDN), platform compliance standards (Windows, Unix, etc.), and quality and safety standards (UL, ISO, CMM).]

8.2 System Requirements

[Define any system requirements necessary to support the application. These can include the supported host operating systems and network platforms, configurations, memory, peripherals, and companion software.]

8.3 Performance Requirements

[Use this section to detail performance requirements. Performance issues can include such items as user load factors, bandwidth or communication capacity, throughput, accuracy, and reliability or response times under a variety of loading conditions.]

8.4 Environmental Requirements

[Detail environmental requirements as needed. For hardware based systems, environmental issues can include temperature, shock, humidity, radiation, etc. For software applications, environmental factors can include usage conditions, user environment, resource availability, maintenance issues, and error handling, and recovery.]

9. Appendix 1 û Objective Attributes

[Objectives should be given attributes that can be used to evaluate, track, prioritize, and manage the product items proposed for implementation. List and briefly describe the attributes you have chosen.á See Artifact:á Requirement Management Plan for a set of suggested feature attributes.]